Proyecto en general

En este documento vamos a encontrar feedback respecto al proyecto en general que no encaja con las demás categorias.

Semana 1

Al contabilizar las horas hay que desglosarlas para saber que trabajo se ha hecho y cuanto ha durado.
El trabajo realizado debe reflejarse en horas por uso de aplicaciones como Clockify.

Es buena idea poner algún documento o cuestionario para colocar las quejas y problemas, y así podemos ver la retrospectiva semanal y solucionar problemas.

Se debe dejar claro la planificación de cada sprint, sobre todo si ha habido problemas de rendimiento en una semana, ¿Cómo afectan las carencias en este sprint a los próximos sprints?
Si no se llega al 100% del trabajo que se pedía, se debe justificar con un motivo de peso o penalizaciones sobre el Commitment Agreement o la evaluación grupal de la persona implicada.
El rendimiento no es la inversión del tiempo si no el uso efectivo del mismo.
El rendimiento se debe medir individualmente y no en grupo.
Si hay una propuesta de mejora se debe decir cómo se va a medir de antemano, antes de tomar la medida.
Las métricas del rendimiento debe ser capaz de comparar cada miembro del equipo y los datos obtenidos deben ser cotejados para evaluar al final de cada sprint. Para los que programan es sencillo; nº de commits… Pero ¿Cómo se está midiendo el rendimiento de la persona que coordina?
Durante el desarrollo dar preferencia a las funcionalidades core o del MVP, por ejemplo, si el login es secundario no debería estar siendo desarrollado en el primer sprint cuando el objetivo es acabar el MVP.
El testing no puede estar presente solamente en el sprint 3, deben ser FAST, se deben hacer a lo largo de todos los sprints.
En caso de tener problemas en el desarrollo, siempre valorar la posibilidad de mover tareas de un sprint a otro.

Enforcarse en el MVP, y si hay que recortar el alcance se recorta, siempre indicando el por qué, para que no se superen las 10 horas de trabajos.

Los fin de semana y días festivos (semana santa y feria) deben de contar como días no laborables.
Si se han excedido las horas de trabajo en un sprint hay que intentar compensar en el próximo Sprint, ya sea recortando el alcance o replanificando para no excedernos en el presupuesto.
Hay que realizar un commitment agreement para los usuarios piloto.

Se debe realizar una justificación si se quiere recortar el alcance.
Se debería usar una API para comprobar que los correos sean válidos.
Utilizar un calendario compartido.
Hacer mejor uso de los conventional commits (Por ejemplo con changelogs automáticos)
La base de datos debe contener datos realistas
Hay que asociar el Costumer Agreement al desarrollo del servicio, con los contratos de uso y alquiler de servicios en la nube.
Hay que tener en cuenta el impacto legal del proyecto (aceptar terminos legales de uso, políticas de protección de datos, etc)

Hay que saber medir cuando, aún habiendo mucho esfuerzo en una tarea, si se da una corrección o una recomendación, aceptar estas y realizar algo de retrospectiva en lugar de tratar de defenderla a cualquier costo.
Si alguien disminuye su rendimiento de manera constante es necesario tomar algún tipo de medida, hablarlo con él y llegar a algún tipo de solución para que la tendencia no siga.
Hacer fotos más formales (Usar misma camiseta y pose y no tener fondo o tener fondo muy simple).